Utilizing the power of CGI-like programs on the GUI desktop...
Using command line parameters as messenger systems between applications.
Inter-Parameter-Inter-Application-Heaven.
Windows users see the command line as obsolete and useless. Gnu/Linux users use command line parameters quite often by hand, typing out and memorizing things they could have just made a small GUI for. But the command line is useful for more than just typing in command line parameters by hand.
This page will mostly focus on using command line parameters as messaging systems or middlemen between applications. This is not about overusing and abusing the command line by hand with your keyboard. This page is about educating users to start using the command line parameters in order to make their own mini-API's, middlemen applications, application server interfaces.. all without the overhead of a Win32 based API or a plug in system, or a library (DLL). This knowledge can also be used for gnu/linux, but this page has been created using windows examples.
Command Line Parameters are very powerful, because no DLL's or custom API's are needed to make your own messaging system. This is essentially what CGI, PHP, and any web application use. The over head is the fact that you have to call upon a new process each time you wish to fire up your exe which acts as your messenger. But the overhead is not the same as you would think, since the command line programs are much faster than GUI programs.
On the Windows desktop, people rarely use command line parameters and mini messenger programs for advanced inter-program hacks these days. The windows API and things like Microsoft DotNet are overused and over-hyped, but what about the power of command line parameters and little mini messenger programs created by yourself, in a multi-tasking environment? Little exe's and/or batch files/command files can act as message receivers and senders between two applications. Are you going to call on 10MB of DLL's like shellapi, kernel32, user32, etc. or 100 MB of Dot Net just to create a new file on the fly and launch a program? Or are you going to spawn a new process for a little 60K program which does all sorts of magic between programs. That is the reason we say that although spawning a new process seems like "overhead" the fact is that many DLL's cause more overhead than spawning a new process (such as in comparing hefty PHP libraries to small CGI programs).
What does the command line parameter system offer? Think about how a CGI or PHP website is run, or any website that uses URL variables (environment variables).
Example:
somesite.com/form/submit?n=5&page=6
That above n=5 and page=6 is essentially your OWN little "API" that you created. You get the environment variables each time someone submits a request.
It's useful on the web, yet people rarely think that it could also be useful on their desktops. Let's take for example a text editor or file manage program that allows you to create your own toolbar widgets which launch programs, and parameters can be specified. Although this is useful for using existing programs, i.e.
notepad myfile.txt
or
notepad $macro
or
notepad %macro
it can also be useful from a programming perspective.
customprogram -message1 -message2 -delete -copy -movewindows -closewindows
or
customprogram %m1 %m2 %del:somefile %cop:somefile %mwins:somewindows %cwins:somewindows
Make your customprogram.exe, which you compiled, respond to environment variables.
Since you are just doing basic but powerful things, you are actually creating a mini-API which is like a plug in for your application, who didn't have a plug-in system. When the program receives the paramstr(3) it gets the message to "delete some file" or paramstr(4) to copy some file, you are using the power of a CGI like program on the windows desktop. I've rarely seen this . usually command line parameters are purely used for simple basic things like launching notepad and automatically opening a file. No one ever thought that it could used as a "powerful middleman" between applications.. (well some people do) ... people just use command line parameters as a "weak middleman" between applications.
What is meant by powerful middleman? The difference is that when you create your own exe program that first filters or pre-processes your command line parameters, this is more powerful than just sending the parameter directly to an existing application. The exe that you create which acts as your middleman, is much more powerful of a middleman than not having the exe there at all, and just sending the parameters directly to some existing application.
Let's say you want to quickly create a new file, minimize some windows, close some windows, compile a program, upload a program to FTP, and then immediately edit some file in one of your favorite editor programs. This would be impossible to do with just simple command line parameters sent directly to one single application. However, if you create your own exe to handle the parameters, you can do this without trouble.
program middleman;
begin
// grab paramstr() items first..
//...
// ...and based on those..
//
// create a new file...
//...
// use WinApi Calls to minimize some windows
//...
// close some windows too
//...
// upload some fil to FTP
//...
// set focus to an editor window with a WinApi call or similar
end.
You're middleman connects to several applications and does many things. The point is to make a middle man daemon that responds to a request from your sender program.
If your program doesn't have the ability to create new files on the fly, and it doesn't have a plug in system, and it doesn't have an API.. but it DOES have simple access to Toolbar Widgets (i.e. custom tool menu creation) you could create a program your self that responds to parameters and makes a call to CreateFile() or similar. Therefore you can extend your crippled application with NO API by creating your own command line API with your own program. You control the API now, not the original software developer. As long as the software developer gives you access to the command line launching from a Toolbar menu. (Editplus, total commander, Syn, are examples that have this custom toolbar feature with %macros you can specify).
Command line programs that respond to parameters and environment variables would just be a small in size, since they basically call some of your I/O command line functions. But GUI applications of course can also respond to parameters too, not just command line ones. Therefore one could link an existing software application like totalcommander to a middleman GUI application, too, using command line parameters without any api (the command line parameters ARE the api).
If the program has a "make your own toolbar" option where you can specify your own command line parameters, then you can use this more powerfully than you would think. Normally, you would re-use other programs.. i.e. notepad or a file manager. Open the current file in notepad, open the current directory in an editor, etc.
But when you need to extend your application to do wild things, notepad or a file manager isn't going to do anything special. If the program lacks a plug in interface, you can't extend the application.. and plug in interfaces are some times annoying and time consuming things to work with if there is one (i.e. Delphi Open Tools API is a piece of brown poo).
If you want to extend a software application, you can use command line parameters and a CGI like program on the desktop. Let's say you create a 15KB command line EXE that does something for you when a certain parameter is passed to it. Like CGI, this would be like a "request" to do something. On the desktop, you may want to create a file, copy a file, open programs, pop up a dialog window asking a question, launch a web browser but then close it right away. All this can be done if you make your own EXE program that has it's own mini API through the command line parameters.
The possibilities are unlimited. The command line and parameters offer the ability for you to make desktop like CGI programs. Build a small executable command line program which responds to paramstr() and based on those parameters, does magic like things that you need to do. This is creating your OWN API on the fly, having full control of your OS.. all by using the obsolete command line. The fact is that command lines are not obsolete, and they are even more powerful than the windows API.
At this time in life, it's not about using command lines or using DOS.. or being a command line weenie.. it's understanding that command line's and parameter strings can make a GUI application so much more powerful than a fixed API or a fixed compiled program. IF you think about CGI (or PHP, or any web architecture that uses url variables) and apply it's power to the desktop, you'll have a much more powerful desktop.
Plug in interfaces in applications can sometimes take for ever to implement or explain to your users, and they are limited. But with parameter strings, and user of your application can make his own programs who respond to those parameter strings.
Parameter strings can connect two applications together through your OWN API, even though you didn't think of it as an API maybe back in the Dos days.
Linux overuses command line (from doing basic things that should be done in a GUI) .. but Windows over uses the GUI and doesn't realize of the power of the command line (using things like DDE and OLE, COM and DotNet when some of that power has been already available through the command line for ages). Combining the GUI and the command line power is having the most power. Linux users need to learn that there is more of a place for GUI on the desktop, and windows users need to learn that the GUI needs to be integrated with the command line more frequently. And compiler folks like Borland and DotNet architecture people need to learn that the command line is not out and never will be out, and that it's got potential power, but people aren't using it. People think that the command line is obsolete because it's unrelated to GUI, but in fact the entire Internet is run from the command line (cgi, PHP) and that's on of the reason that the entire Internet works. PHP and Perl are scripting languages and the CGI is hidden from them, so they also could see more power that the command line offers to the desktop GUI, if they got more acquainted with CGI.
On a website, a page can pass variables to another page through environment variables, which are essentially command line parameters.. yet in GUI applications you never see this as often as you should. One application can send information to another application through environment variables too, not just websites. It's faster and more powerful than the windows API or a plug in system, because each user can make his own relay programs which receive and output other messages to other applications. Who needs DDE or COM?
Windows does recognize are need for command line parameters in very simple ways. People open notepad and it automatically opens a file for them based on command line parameter. Big Deal. This is not showing the power of what a command line parameter system can do on the GUI.
Real world examples
What could you do with these mini-messenger systems or middleman exe's between applications then?
1. You need a copy of total commander or Syn editor on hand, or any program that has
access to custom toolbar buttons, custom menu tools, which offer command line
parameters (EditPlus and many programs have this too).
2. Make a custom toolbar button in the program. With each custom toolbar button you
create, you have access to "parameters" which you can send to a program you wish
to launch.
3. Using total commander as an example, let's use a pre-defined macro or pre-defined
command line parameter. We will choose the %L parameter in our example here.
4. The %L parameter makes a list of file selected in total commander, and places them
in a file for you. This is the power of total commander working, but now we want
to involve our own middleman program which actually DOES something with this list
of files.
5. Compile a program in freepascal or Delphi, or your favorite compiler which
responds to paramstr(1). Your paramstr(1) will be %L which is basically a macro
or pointer to a file name with a list of files in it.
6. In your program as you respond to paramstr(1), either use an array or a
stringlist (in pascal) to load the file specified as %L. SO it should look
something like this in pascal:
stringlist.loadfromfile(paramstr(1));
7. Now you have a list of files in your middle man program. Do something with it.
..Launch Excel using shellexec
..send the StringList.Strings into excel using either DDE or OLE server.
What have you just done? You selected some files in total commander, and you
needed them to be placed into an excel worksheet. Instead of copying and pasting,
you did all this in one click. It took some work, since you had to create your
own EXE which responded to your custom request.. but if it's something you are
going to use over and over again, you just built your own custom system which most
people thought was only available to programs who offer a plug-in system or custom API.
You created a middleman EXE program which is similar to a "server" or a "daemon". It, like a server, took your parameter strings and processed them for you. If you see the power of this, you could almost look past DDE and COM and OLE and DOTNET. Creating your own exe's which handle little requests are very powerful.. if you
put them to good use. And they've been available for ages, just people haven't been
using them.
In fact, OLE, COM, dotnet, Win API, and DDE technology may be built on some of the above principles. The command line and parameters we send to it could run a very inter-application powerful operating system.. yet it seems so simple. command line parameters? That's it? Well, the whole Internet is run on this principle (url variable's, post/request).. and it's one HUGE Internet out there isn't it?
It is possible the entire windows operating system and it's messaging service runs on the above principles through the command line. And if not, then it still holds true here that the power of your own exe middle man messaging system is one great thing. What can't you do with your own EXE program, spawned from an application? You can program anything you want into the EXE to do anything you want. This should give you a hint that a middleman EXE is more powerful than DDE, OLE, dotnet, etc... because your own Exe could actually call upon those services itself, and utilize them, if it wanted.
Note: command line parameters are also known as command line "arguments". Command line macro parameters are also known as command line "argument macros". See Argument Macros and Parameter Macros into excel using either DDE or OLE server.
|
